The present invention relates to asynchronous transfer mode (ATM) and the transportation of internet protocol (IP) data packets over a single ATM connection. More particularly, the present invention employs ATM adaption layer two (AAL2) and header compression techniques to more efficiently transport multi-protocol internet data over a single ATM connection in a network environment.
ATM is a standard protocol for transmitting asynchronous telecommunication data. This protocol is based on the transmission of data in fixed size data packets known as ATM cells. Each ATM cell exhibits a singular format comprising a 48 octet payload portion and a 5 octet header portion. ATM is well known in the art.
Unfortunately, ATM does not efficiently transport low bit rate data. The reason being, the length of a typical low bit rate data packet is significantly less than 48 octets (i.e., the length of an ATM cell payload). Any unused portion of an ATM cell payload is filled with "padding bits". When padding bits are inserted rather than data, bandwidth is wasted. It will be understood that inserting padding bits may also result in unacceptable transmission delays, which may be detrimental, especially when the data being transported is highly sensitive to delays, such as voice-type data.
Recently, an ATM adaption layer known as AAL2 has been developed. AAL2 was specifically for the purpose of improving the efficiency of ATM when employed to transport low bit data. Referring to FIG. 2, AAL2 operates by storing low bit rate data in small, variable length data packets called minicells (sometimes referred to as microcells or short packets), for example, minicell 205. Improved bandwidth utilization is achieved by inserting several minicells into the payload of a single ATM cell, such as ATM cell 210. To further improve bandwidth utilization, a minicell, for example minicell 215, may be segmented so that it overlaps two ATM cells as illustrated.,
FIG. 3 illustrates a well known protocol for an AAL2 minicell 301. The minicell 301 is divided into a 3 byte header 302 and a payload 303. The header is, in general, divided into the following fields: a circuit (channel) identifier (CID) 304, a length code 305, a cyclic redundancy code (CRC) code 306, and a user-to-user information (UUI) field 307. The CID 304 provides the information necessary to associate each minicell with a corresponding channel when multiplexing several channels. The length code 305 provides the information needed to determine the location of the first and last octet of each minicell. The CRC 306 provides an integrity check for the minicell header 301, and the UUI field 307 is used in conjunction with the minicell segmentation process.
It is well known in the art that ATM is commonly employed as a bearer for transporting data from point to point in a network environment. Typically, the data packets being transported are initially formatted in accordance with any one of a number of different internet protocols (IPs). Examples of such IPs include the transport control protocol (TCP), the user datagram protocol (UDP) and the real-time transport protocol (RTP).
Conventionally, these IP data packets are further formatted in accordance with a point-to-point protocol (PPP) The primary purpose for using the PPP is that PPP provides a standard format for multi-protocol data packets over point-to-point links. The PPP accomplishes this by encapsulating the different IP data packet types as illustrated in FIG. 4.
The encapsulation model 400 illustrated in FIG. 4 includes several data fields. The PPP protocol ID field 405 is generally 2 octets in length and it identifies the type of IP data packet appearing in the information field 410. For example, the PPP protocol ID field 405 may identify the IP data packet (not shown) as a RTP data packet, a UDP data packet or a TCP data packet. In addition. the PPP protocol ID field 405 establishes whether the header associated with the IP data packet is compressed or uncompressed. The encapsulation model 400 may also include a number of padding bits 415.
FIG. 5 illustrates a typical IP/PPP data packet header 500, more particularly, a TCP data packet header. To improve bandwidth utilization, and transmission efficiency, it is routine practice to compress the IP/PPP data packet header, as is well known in the art. Header compression is based on the fact that a significant number of the data fields in an IP/PPP header, for example IP/PPP data packet header 500, remain constant over the life of the session or connection. For example, FIG. 6 illustrates the data fields in the IP/PPP data packet header 500 that remain constant. Accordingly, a full header may be transmitted when the session/connection is first established. By transmitting a full header first, the decompressor can be configured to accommodate compressed headers during the remainder of the session/connection. Thereafter, only those fields that change need be transported. In fact, it is possible to further compress IP/PPP data packet headers even further by taking advantage of those fields that change periodically or that change by a constant value, as is well understood in the art. The specific data fields which remain constant, change periodically, or change by a constant value, depend on the IP/PPP data packet type.
Frequently, networks service more than one type of application, wherein each application produces data that exhibits a unique data transfer format. In order to employ ATM, each of the different data transfer formats must be reformatted (i.e., adapted) to conform to the ATM format. This is accomplished by one of several ATM adaption layers (AALs), for example AAL 101 illustrated in FIG. 1, wherein the application layer 102 represents data (e.g., internet protocol data) arriving from a particular application. More specifically, the AAL 101 stores the application data in the payload portion of one or more ATM cells. The ATM layer 103 then transmits the one or more ATM cells to a receiving point in the network.
There are several well known AALs. Two of the most widely used AALs are AAL1 and AAL5. AAL1 is used for transporting synchronous data (i.e., circuit emulation data). AAL5, on the other hand, is used for transporting packet data, for example, IP packet data.
In networks that employ ATM as a bearer for IP/PPP data packets, AAL5 is the ATM adaption layer used. Since the packet length of each IP/PPP data packet is not typically equivalent to the length of an ATM cell, or more specifically, to the length of an ATM cell payload, the unused portion of the ATM cell payload must be padded after the IP/PPP packet has been inserted therein. As explained above, padding ATM cells or transmitting ATM cells that are not completely filled with data is an extremely inefficient use of bandwidth, and it has the effect of counter-acting any added efficiency achieved by compressing the IP/PPP data packet header. Accordingly, there is a substantial need to provide a more efficient way to transport IP/PPP data packets when using ATM as a bearer.